Method and apparatus for scalable virtual private network multicasting

ABSTRACT

In one embodiment, the present invention is a method and apparatus for scalable virtual private network multicasting. In one embodiment a service network builds a new data multicast distribution tree for each high-bandwidth multicast data flow (e.g., multicast data flows that require an amount bandwidth meeting or exceeding a predefined threshold). However, if the multicast data flow is a low-bandwidth flow (e.g., if the required amount of bandwidth falls below the predefined threshold), the multicast data flow is routed over an existing multicast distribution tree in order to minimize an amount of state information that must be maintained by service provider core routers in the backbone network.

FIELD OF THE INVENTION

The present invention relates generally to service networks, and relatesmore particularly to the scaling of multicast virtual private networks.

BACKGROUND OF THE INVENTION

FIG. 1 is a schematic diagram illustrating an exemplary service network100. The service network 100 comprises a multiprotocol label switching(MPLS) service provider backbone network 112 supporting a plurality ofindividual private network sites 102 ₁-102 _(n) (hereinaftercollectively referred to as “sites 102”). A subset of these sites 102forms a virtual private network (VPN). The backbone network 112comprises a plurality of provider edge (PE) routers 106 ₁-106 _(n)(hereinafter collectively referred to as “PE routers 106”) and aplurality of provider core routers 108 ₁-108 _(n) (hereinaftercollectively referred to as “P routers 108”) for receiving andforwarding data (e.g., received from sites 102). Each of the sites 102comprises at least one customer edge router 104 ₁-104 _(n) (hereinaftercollectively referred to as CE routers 104”) that connects the site 102to the backbone network 112. If at least two of the sites 102 aremulticast-enabled, they make up a “multicast domain”.

Each multicast domain has a default multicast distribution tree (MDT)through the backbone network 112 that defines the path used by PErouters 106 to send multicast data and control messages to every otherPE router 106 connected to the multicast domain. In some cases, thisdefault MDT may not be the most optimal means of forwarding data. Forexample, consider a multicast domain comprising sites 102 ₁, 102 ₂ and102 ₃. If a default MDT were used to send data to a subset of sites 102in the multicast domain (e.g., from a sender in site 102 ₁ to a receiverin site 102 ₃), the data would also be forwarded to destinations in themulticast domain that are dead ends, i.e., not on the path to theintended receiver (e.g., PE router 106 ₂). This is wasteful, especiallyfor high-bandwidth multicast traffic, and makes the service network 100very difficult to scale.

One solution to the bandwidth conservation problem is the implementationof individual MDTs for specific multicast groups, referred to as “dataMDTs”. A data MDT (e.g., data MDT 110, illustrated as a dashed line)delivers VPN data traffic for a particular multicast group (e.g.,comprising sites 102 ₁ and 102 ₃) only to those PE routers 106 that areon the path to receivers of the multicast group. This reduces the amountof multicast traffic on the backbone network 112 and reduces load onsome PE routers 106. However, it also increases an amount ofVPN-specific state knowledge (e.g., routing information) that must bemaintained by the P routers 108, as a separate MDT must be maintainedfor each multicast source or multicast group. Therefore, the problem ofscalability remains.

Thus, there is a need in the art for a method and apparatus for scalablevirtual private network multicasting.

SUMMARY OF THE INVENTION

In one embodiment, the present invention is a method and apparatus forscalable virtual private network multicasting. In one embodiment aservice network builds a new data multicast distribution tree for eachhigh-bandwidth multicast data flow (e.g., multicast data flows thatrequire an amount bandwidth meeting or exceeding a predefinedthreshold). However, if the multicast data flow is a low-bandwidth flow(e.g., if the required amount of bandwidth falls below the predefinedthreshold), the multicast data flow is routed over an existing multicastdistribution tree in order to minimize an amount of state informationthat must be maintained by service provider core routers in the backbonenetwork.

BRIEF DESCRIPTION OF THE DRAWINGS

The teaching of the present invention can be readily understood byconsidering the following detailed description in conjunction with theaccompanying drawings, in which:

FIG. 1 is a schematic diagram illustrating an exemplary service network;

FIG. 2 is a flow diagram illustrating one embodiment of a method forsending MVPN traffic over a service provider backbone network (e.g., anMPLS network); and

FIG. 3 is a high level block diagram of the present VPN multicastingsystem that is implemented using a general purpose computing device.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures.

DETAILED DESCRIPTION

In one embodiment, the present invention relates to the scaling ofmulticast virtual private networks (MVPNs). In one embodiment, a dataMDT is created only for data transmissions requiring an amount ofbandwidth that exceeds a predefined cumulative threshold. An aggregateddata transmission that requires an amount of bandwidth falling below thepredefined threshold may be sent over an existing MDT, substantiallyeliminating the need to create a discrete MDT for every data flow andreducing the amount of state information that must be maintained byservice provider routers. An MVPN implementing such a scheme istherefore substantially more scalable than existing MVPNs.

Moreover, the re-use of existing MDTs as described above facilitatesbandwidth optimization for MVPNs by maintaining the efficiency ofbandwidth usage on P and PE routers. As will be discussed in greaterdetail below, exhausted data MDTs may be re-used based on a best matchto the optimal tree for a given flow of multicast traffic. In someembodiments, a new data MDT is not even created for a given flow ofmulticast traffic until it can be determined whether an existing dataMDT is optimal for the given flow.

FIG. 2 is a flow diagram illustrating one embodiment of a method 200 forsending MVPN traffic over a service provider backbone network (e.g., anMPLS network). The method 200 may be executed at, for example, a PErouter 106 that is connected to a multicast domain comprising two ormore customer sites 102. For the purposes of discussion, assume that themethod 200 executes at PE router 106 ₁ of FIG. 1. The method 200 isinitialized at step 202 and proceeds to step 204, where the method 200receives multicast traffic from a source in a first customer site (e.g.,site 102 ₁). The multicast traffic is intended for at least one receiverin at least a second site 102 connected to the backbone network 112. Forexample, the method 200 may receive multicast traffic from a source insite 102 ₁ that is intended for a first receiver in site 102 ₂ andsecond a third receivers in site 102 ₃.

In step 206, the method 200 determines whether a predefined sourcebandwidth threshold for an MDT in the service network 100 issingle-source based (e.g., such that the threshold applies to the sourcebandwidth for a single multicast traffic flow) or cumulative-sourcebased (e.g., such that the threshold applies to a sum of sourcebandwidths for a plurality of multicast traffic flows flowing over asingle MDT at one time). In one embodiment, the type and value of thethreshold is user-definable and depends on an acceptable degree ofextraneousness and/or a desired level of scalability for a particularnetwork or application, as described in further detail below.

If the method 200 determines in step 206 that the threshold issingle-source based, the method 200 proceeds to step 208 and determineswhether the source bandwidth meets or exceeds the predefined threshold.If the source bandwidth does meet or exceed the predefined threshold,the method 200 proceeds to step 210 and builds a new data MDT for thereceived traffic, e.g., in accordance with known methods for buildingdata MDTs.

Alternatively, if the method 200 determines in step 208 that the sourcebandwidth does not meet or exceed the predefined threshold, the method200 proceeds to step 212 and routes the received multicast traffic overan existing data MDT. In one embodiment, the step 210 of routing thereceived multicast traffic over an existing data MDT includesidentifying an existing data MDT that best matches an optimaldistribution tree for the received multicast traffic. In one embodiment,the best-matching existing data MDT services every intended receiver ofthe received multicast traffic (e.g., by servicing the associated PErouters 106) and also services the least number of extraneous oruninterested receivers. In one embodiment, such a method is implementedwhere no more data MDTs can be built (e.g., the multicast addressesassigned to the data MDTs have been exhausted).

Referring back to step 206, if the method 200 determines that thebandwidth threshold is not single-source based (e.g., iscumulative-source based), the method 200 proceeds to step 214 anddetermines whether the source bandwidth meets or exceeds thecumulative-source based threshold. If the threshold has not yet beenmet, the method 200 proceeds to step 216 and routes the received trafficover an active new type of MDT, hereinafter referred to as a “super dataMDT”. A super data MDT is an MDT that has a root at the receiving PErouter (e.g., the PE router 106 ₁ at which the method 200 is executingand which directly services the source of the received multicasttraffic) and spans all other PE routers 106 in the MPLS VPN that serviceinterested receivers for at least one flow of multicast traffic(including the received multicast traffic) having a source serviced bythe root PE router 106 ₁.

Alternatively, if the method 200 determines in step 214 that the sourcebandwidth does meet or exceed the cumulative-source based threshold, themethod 200 proceeds to step 218 and either builds a new data MDT for thereceived traffic (e.g., in accordance with known methods for buildingdata MDTs) or re-uses an existing data MDT for routing the receivedtraffic (e.g., in a manner substantially similar to step 212). If themethod 200 builds a new data MDT, this new data MDT will span all PErouters 106 that service interested receivers for the received multicasttraffic. The method 200 then terminates in step 220.

A super data MDT will be active for as long as there is at least onemulticast flow currently being received by the root PE router (e.g., PErouter 106 ₁) and at least one interested receiver for the receivedmulticast flow. Moreover, if a given PE router 106 does not service anyinterested receivers for any multicast data flow sourced at the root PErouter, traffic from the root PE router is not sent to the given PErouter.

It will be apparent that in some cases, the routing of multicast trafficover an existing data MDT (e.g., in accordance with steps 212 or 218)will result in multicast traffic being sent to PE routers that do notservice any interested receivers for a particular flow of multicasttraffic. Thus, the predefined threshold that is assessed in steps 208and 214 should define a threshold below which the required bandwidth isacceptably low for such extraneousness (e.g., the required bandwidth islow enough that the multicast traffic may be dropped by an extraneous,uninterested PE router with minimal concern or consequence). Asdiscussed above, this level of acceptable extraneousness may depend onthe particular application or on desired network performance orscalability (e.g., as defined by a service level agreement).

In this way, the amount of state information that must be maintained bythe network's P routers 108 is minimized. Specifically, the amount ofstate information maintained by the P routers 108 according to themethod 200 remains more proportional to the number of VPNs on thenetwork 100, rather than proportional to a number of individualmulticast groups or multicast traffic sources. This creates less churnin the backbone network 112, thereby substantially stabilizing thebackbone network 112. Moreover, the reduced amount of state informationthat is maintained in the P routers 108 allows the service network 100to be scaled more easily than a traditional MPLS VPN system.

Further, in one embodiment, the method 200 is implemented only to carrymulticast traffic, and all control traffic is transported along thedefault MDT, thereby further stabilizing the default MDT.

FIG. 3 is a high level block diagram of the present VPN multicastingsystem that is implemented using a general purpose computing device 300.In one embodiment, a general purpose computing device 300 comprises aprocessor 302, a memory 304, a VPN multicasting module 305 and variousinput/output (I/O) devices 306 such as a display, a keyboard, a mouse, amodem, and the like. In one embodiment, at least one I/O device is astorage device (e.g., a disk drive, an optical disk drive, a floppy diskdrive). It should be understood that the VPN multicasting module 305 canbe implemented as a physical device or subsystem that is coupled to aprocessor through a communication channel.

Alternatively, the VPN multicasting module 305 can be represented by oneor more software applications (or even a combination of software andhardware, e.g., using Application Specific Integrated Circuits (ASIC)),where the software is loaded from a storage medium (e.g., I/O devices306) and operated by the processor 302 in the memory 304 of the generalpurpose computing device 300. Thus, in one embodiment, the VPNmulticasting module 305 for scalably multicasting over VPN systemsdescribed herein with reference to the preceding Figures can be storedon a computer readable medium or carrier (e.g., RAM, magnetic or opticaldrive or diskette, and the like).

Thus, the present invention represents a significant advancement in thefields of service networks and VPN multicasting. A method is disclosedthat not only optimizes bandwidth consumption in MVPN systems, but alsoenables such systems to be scaled in a feasible and stable manner.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of a preferred embodiment shouldnot be limited by any of the above-described exemplary embodiments, butshould be defined only in accordance with the following claims and theirequivalents.

1. A method for sending multicast data from a source to at least onereceiver, the method comprising: providing at least one existingmulticast distribution tree; building a new data multicast distributiontree for sending said multicast data to said at least one receiver if anamount of bandwidth required to send said multicast data meets orexceeds a predefined threshold; or sending said multicast data to saidat least one receiver over an existing multicast distribution tree ifsaid amount of bandwidth required to send said multicast data fallsbelow said predefined threshold.
 2. The method of claim 1, wherein saidpredefined threshold is cumulative such that a sum of source bandwidthsfor a plurality of multicast data flows sent over a single existingmulticast distribution tree falls below said predefined threshold. 3.The method of claim 1, wherein said predefined threshold is definedbased on at least one of an acceptable degree of extraneousness and adesired level of service.
 4. The method of claim 1, wherein saidexisting multicast distribution tree serves at least said at least oneprovider edge router servicing at least one interested receiver.
 5. Themethod of claim 1, wherein said source resides on a first virtualprivate network site, and said at least one intended receiver resides onat least a second virtual private network site, said first virtualprivate network site and said second virtual private network site beingconnected to a common service provider backbone network.
 6. The methodof claim 5, wherein said service provider backbone network is amultiprotocol label switching network.
 7. The method of claim 1, whereinsaid building and sending steps are implemented to carry multicasttraffic only, and control traffic is carried along a default multicastdistribution tree.
 8. The method of claim 1, wherein said existingmulticast distribution tree is a super data multicast distribution tree.9. The method of claim 8, wherein said super data multicast distributiontree is a multicast distribution tree having a root at a provider edgerouter servicing said source and spanning all other provider edgerouters that service interested receivers for said multicast data,including said at least one receiver.
 10. A computer readable mediumcontaining an executable program for sending multicast data from asource to at least one receiver, where the program performs the stepsof: providing at least one existing multicast distribution tree;building a new data multicast distribution tree for sending saidmulticast data to said at least one receiver if an amount of bandwidthrequired to send said multicast data meets or exceeds a predefinedthreshold; or sending said multicast data to said at least one receiverover an existing multicast distribution tree if said amount of bandwidthrequired to send said multicast data falls below said predefinedthreshold.
 11. The computer readable medium of claim 10, wherein saidpredefined threshold is cumulative such that a sum of source bandwidthsfor a plurality of multicast data flows sent over a single existingmulticast distribution tree falls below said predefined threshold. 12.The computer readable medium of claim 10, wherein said predefinedthreshold is defined based on at least one of an acceptable degree ofextraneousness and a desired level of service.
 13. The computer readablemedium of claim 10, wherein said existing multicast distribution treeserves at least said at least one provider edge router servicing atleast one interested receiver.
 14. The computer readable medium of claim10, wherein said source resides on a first virtual private network site,and said at least one intended receiver resides on at least a secondvirtual private network site, said first virtual private network siteand said second virtual private network site being connected to a commonservice provider backbone network.
 15. The computer readable medium ofclaim 14, wherein said service provider backbone network is amultiprotocol label switching network.
 16. The computer readable mediumof claim 10, wherein said building and sending steps are implemented tocarry multicast traffic only, and control traffic is carried along adefault multicast distribution tree.
 17. The method of claim 10, whereinsaid existing multicast distribution tree is a super data multicastdistribution tree.
 18. The method of claim 17, wherein said super datamulticast distribution tree is a multicast distribution tree having aroot at a provider edge router servicing said source and spanning allother provider edge routers that service interested receivers for saidmulticast data, including said at least one receiver.
 19. Apparatus forsending multicast data from a source to at least one receiver, theapparatus comprising: means for providing at least one existingmulticast distribution tree; means for building a new data multicastdistribution tree for sending said multicast data to said at least onereceiver if an amount of bandwidth required to send said multicast datameets or exceeds a predefined threshold; and means for sending saidmulticast data to said at least one receiver over an existing multicastdistribution tree if said amount of bandwidth required to send saidmulticast data falls below said predefined threshold.